New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Python 2 EOL Roadmap? #403
Comments
I would love an effort to make our python code 2/3 compatible. Are there tools in the python world that can identify 2/3 compatibility problems in python programs and modules? Maybe through static analysis? "Flake" maybe? If so we should add build-time tests to run them; for now the test will just warn on failures, then once we have full 2/3 compatibility we'll switch it to fail the build on failures. |
|
I agree, that we should go the way to write code for both python versions. A good way to start is also the page: I will check also on pylint Norbert |
The python code will be easy to convert to work with both Python 2 and 3, the part I am not so sure about is the C/C++ python bindings. I think boost python is used for those. We probably will have to add a switch to compile for one or the other version of python. Ideally the bindings would work with both, but I am not sure how feasible that is. |
Note that you don't have to have the same code work for both. There are many packages written for Py2k that support py3k via |
@fake-name as Kurt mentioned, the key problem is the c/c++ binding code. |
Here's somebody else's experience converting an old, big python2 codebase to python3: https://medium.com/@boxed/moving-a-large-and-old-codebase-to-python3-33a5a13f8c99 There might be something helpful for us to glean from this.... |
FWIW, I'm rewriting It actually resulted in Actually, I'm unclear why |
SebKuzminsky: An interesting read there. I see nothing of python extensions or python embedding unfortunately, which of course is the hardest part. It's a good reference though. |
@fake-name It's great that you are taking an interest in working on axis and on the externally imposed python2 time bomb that our project faces. Thank you. But even as you have the urge to rewrite axis.py wholesale (who doesn't? It's more a question of having the energy to do so), please keep in mind how you'll be able to ultimately create that as a pull request where the individual commits are reviewable. This is particularly important since we don't have any tests of GUI components of LinuxCNC, like AXIS. (Unless you're going to fix that too. 😉) A single commit in which the whole structure and design of axis.py is upended is probably unreviewable and is likely to languish indefinitely as a pull request. The way lots of direct access to Tcl/Tk is mixed with Python/Tkinter does have an historical motivation: Long ago at my $DAY_JOB, I created a GUI builder for Tcl, which I got permission to release as an open source product. (it didn't gain any users and the open source version is unmaintained) A never-realized goal was for programmers to be able to reconfigure the AXIS UI by modifying it in the GUI builder. AXIS never achieved this goal, and eventually the GUI builder files were renamed to ".tcl" and when it felt expedient, developers (mostly me) wrote code in Tcl instead of in Python. Coming from my particular $DAY_JOB's background, mixing Python and Tcl like this doesn't even feel weird; but I know it's not common practice in widely published or read open source Python projects. |
My primary focus here is to get axis into a state where I can extend it as an internal testing tool for work-related things. The rework is basically only because the code is impenetrable as-it-is, due to the complete lack of structure. Anyways, this would never be a single commit, but rather a series of incremental changes which maintain functionality with incremental refinement. |
I had a go at this today, and after some help from @jepler stuff started to build. |
my work in progress branch is here: #416 |
Just adding something from the source on the topic: from: also this: http://python-future.org/automatic_conversion.html |
I'll add this proof-of-concept branch of using cython for HAL bindings. |
I pulled a few python3 fixes into master, and configure and and python syntax checks are now working. |
It does compile now, and: |
Adding my small contribution for those keen on experimenting / assisting I have been keen to learn C++ for a while and I can find my way around Python so I decided to give this a bash and see how far I get. This is also the first time I have used git or contributed to any project, so please excuse any ignorance. I have forked 2.8 to https://github.com/gibsonc/linuxcnc/tree/2.8 https://docs.python.org/3/c-api/objbuffer.html I still need to get my head around that. As a result a lot of the tests currently fail. On Mint 19 |
Just an update for the curious. It is a lot of work, mostly repetitive, but more things are starting to work now. Thanks to @jepler for his assistance. I cut down on another ten failed tests this evening and with what he taught me I think I will be able to resolve a few more quite soon. I am no coder but I am learning fast and if I can learn so can anyone else :) |
if you interested in i've ported C code and all features i needed worked for me (it was some time ago, hoping this helps you, unfortunately it is a bit behind current master, let me know if i could help here, the only thing i've disabled was related to shmbuffer_procs also found in old mail lists that it is not being used by anyone, also there are no tests for that interface, so seem it needs some discussion ) |
Oh man - how I wish I had seen your work before I started. Nothing is wasted however - I have learned a lot from practically nothing. I didn't know about py3c - it makes all this Bytes / Unicode pain go away that I am currently experiencing. I fix it, but it seems to be by chance and that is never a good thing. Ideally the code must check for the types and return the correct type. |
Make a paralel branch and commit faster your work to it :) |
Maybe we should all choose one branch and all work on it? Maybe this one, as it is already in the LinuxCNC repository? |
Hi, I just installed Debian Buster on a VM and compiled dgarr/py3 branch as RIP. No big issues to install. the Buster I downloaded was the '10.2 amd64 net install' iso, and python 2.7 was the default version, so I had to 'update-alternatives' to set python 3.7 as the default version. I can report that importing hal works with python3 and also axis seems to work (sim mode only..) |
I am currently working on this, picking the best of the attempts that have been made, and getting them up to speed with master. |
status update: working:
not working:
not tested:
This is the roadmap I came up with:
py3c is not available, on wheezy, so either drop support for wheezy(#743), or see if it still works for python2 if you bundle py3c. currently the roadblock is gtk2. not all gtk2 bindings are available in python3. |
gtk3 gtkglarea problem has been fixed, waiting for them to accept the PR |
done, master now build with python3, and all but one tests pass. |
Huge congrats to @rene-dev and the others who accomplished this, and huge thanks, too: we're borrowing from your work over at machinekit/machinekit-hal#114 . You all rock. |
When I download the Raspberry Pi 4 image, the linuxcnc python module seems to only be available when running python 2. Does that image not have the latest, or has that not been addressed yet? |
LinuxCNC 2.8 still uses Python 2. Master / 2.9 has made the switch to Python 3, but not everything is working yet. |
Gotcha, thanks @andypugh! |
LinuxCNC includes a lot of python components, and as everyone is probably aware, Python 2 is EOL in a little more then 2 years.
What's the roadmap for the python 3 migration?
It might be a decent idea to start requiring that people who touch python files make them support either platform. It's completely possible to write python code that works in both versions.
The text was updated successfully, but these errors were encountered: